Pre-Fetching Map Data Based on a Tile Budget

ABSTRACT

To select map data for storage in a memory of a computing device, geographic locations for which a user of a client device is expected to subsequently request digital maps are determined. Prior to receiving a user request for map data related to the geographic locations, pre-fetch map data for generating digital maps including the plurality of geographic locations is determined. Further, a memory budget for storing map data in a memory of the client device is determined along with a priority for retrieving map data from a remote database to the memory of the client device. At least a portion of the determined pre-fetch map data is retrieved from the remote database to the memory of the client device in accordance with the determined memory budget and the determined priority.

FIELD OF TECHNOLOGY

The present disclosure relates to map data optimization and morespecifically to a system and a method to pre-fetch map data from aremote map database.

BACKGROUND

With the widespread use of mobile devices, such as mobile phones,personal data assistants, tablet personal computers, etc., consumerdemand for ready access to varied types of data continues to grow at ahigh rate. These devices are used to transmit, receive, and store text,voice, image, and video data. Consumers often look to store largenumbers of applications on these devices, such that mobile devices areoften touted more for the number of available applications, thaninternal processor speed. While consumers have come to desire fastaccess to data, the sheer amount of data required to run theseapplications places a premium on data management, both at the devicelevel and at the network level. This premium limits the effectiveness ofapplications such as mapping applications, which typically requirecomparatively large amounts of network data.

Mapping applications are found in a variety of mobile devices, includingcar navigation systems, hand-held GPS units, mobile phones, and portablecomputers. These applications are among the most frequently usedapplications and are considered, by some, necessary for modern living.Although the underlying digital maps are easy to use from a user'sperspective, creating a digital map is a data intensive process. Everydigital map begins with a set of raw data corresponding to millions ofstreets and intersections. That raw map data is derived from a varietyof sources, each providing different amounts and types of information.To effectively map a location, locate a driving route between a sourceand a destination, identify points of interest, etc. requiressubstantial amounts of data. Furthermore, many mapping applicationsrequire display of different map data at different zoom levels, i.e.,different scales, where the amount of detail and that nature of thatdetail changes at each zoom level. For example, at a lowest zoom level,scaled farthest away from a target, the map data may contain theboundaries of continents, oceans, and major landmasses. At subsequentzoom levels, that map data may identify countries, states, homelands,protectorates, other major geographic regions. While at even furthersubsequent zoom levels, that map data may contain major roads, cities,towns, until eventually the map data contains minor roads, buildings,down to even sidewalks and walk ways depending on the region. The amountof detail is determined by the sources of information used to constructthe map data at each zoom level. But no matter the zoom level, theamount of information is voluminous and generally too large for storage,in total, on mobile devices and too large for continuous download over awireless communication network.

In operation, mapping applications typically download map data to themobile device through a wireless communication network and in responseto a user entering a location of interest and/or based on the currentlocation of the mobile device, such as the current global positioningsatellite (GPS) data or current cellular network location data for thedevice. A conventional technique for downloading map data is to have themobile device communicate this location data to a remote processor onthe wireless communication network, which, in response, downloads allmap data to the mobile device or the map data requested for display tothe user.

Generally speaking, the map data is stored in blocks known as map datatiles, where the number of map data tiles increases with zoom level. Theremote processor provides a subset of the available map data tiles for aparticular location or region to the mobile device for storage anddisplay at any particular time via a map display application. Byproviding large numbers of map data tiles, the mobile device may bufferthe map data for display to the consumer as the consumer scrolls acrossan area using the mapping application looking for adjacent or othermapping locations. However, the larger the number of map tiles providedat any particular time increases the download time and buffer memoryusage while the user is using the map display application.

Conventionally, map data tiles are downloaded and cached, but in a crudemanner that is unable to take advantage of memory surpluses on devicesand unable to take advantage of network bandwidth surpluses, e.g., whenthe user is not using the device. The conventional techniques aresimilarly deficient in the face of lacking memory and reduced bandwidth.As a result, there is a need to have more intelligent mechanisms fordownloading map data, in particular map data tiles, to sufficientlysatisfy the needs of the user, while doing so in a manner that addressesnetwork bandwidth and memory conditions.

SUMMARY

In an embodiment, a computer-implemented method comprises: identifying,on a client device, one or more map points of interest; identifying,based on the map points of interest, pre-fetch map data tiles to berequested from a remote map database and stored on the client device foreventual rendering of a visual display of map data in response to asubsequent user request; requesting, from a remote map database storingthe map data, the pre-fetch map data tiles corresponding to one or moremap points of interest; receiving, at the client device, the pre-fetchmap data tiles from the remote map database and, during receiving of thepre-fetch map data tiles, determining, at the client device, if the tilebudget has been met by the received pre-fetch map data tiles, where, ifa tile budget has been met, the client device stops receiving additionalpre-fetch map data tiles from the map database, and if the tile budgethas not been met, the client device, continues receiving additionalpre-fetch map data tiles from the map database until the tile budget ismet or until all pre-fetch map data tiles corresponding to the one ormore map points of interest have been received at the client device; andstoring the received pre-fetch map data tiles in a local memory on theclient device until a subsequent user request.

In another embodiment, a computer-readable medium storing instructions,the instructions when executed by a processor cause the processor to:identify, on a client device, one or more map points of interest;identify, based on the map points of interest, pre-fetch map data tilesto be requested from a remote map database and stored on the clientdevice for eventual rendering of a visual display of map data inresponse to a subsequent user request; request, from a remote mapdatabase storing the map data, the pre-fetch map data tilescorresponding to one or more map points of interest; receive, at theclient device, the pre-fetch map data tiles from the remote map databaseand, during receiving of the pre-fetch map data tiles, determining, atthe client device, if a tile budget has been met by the receivedpre-fetch map data tiles, where, if the tile budget has been met, theclient device stops receiving additional pre-fetch map data tiles fromthe map database, and if the tile budget has not been met, the clientdevice, continues receiving additional pre-fetch map data tiles from themap database until the tile budget is met or until all pre-fetch mapdata tiles corresponding to the one or more map points of interest havebeen received at the client device; and store the received pre-fetch mapdata tiles in a local memory on the client device until a subsequentuser request.

In yet another embodiment, a computer system for fetching map tile datato be used in constructing a visual display of map data on a clientdevice, the computer system comprises: a display module for constructingand displaying the visual display of the map data, where the map data isstored in a remote map database as a plurality of map data tiles; a mappoint identifier module that identifies one or more map points ofinterest that define pre-fetch map data tiles to be requested from aremote map database and stored on the client device for eventualrendering of a visual display of map data in response to a subsequentuser request; a database interface module to request, from the mapdatabase, the pre-fetch map data tiles from the remote map database andto receive the pre-fetch map data tiles from the remote map database;and a tile budget module that, during receiving of the pre-fetch mapdata tiles, is to determine if the tile budget has been met by thereceived pre-fetch map data tiles, where, if the tile budget has beenmet, the database interface module is to stop receiving additionalpre-fetch map data tiles from the remote map database, and if a tilebudget has not been met, the database interface module is to continuereceiving additional pre-fetch map data tiles from the map databaseuntil the tile budget is met or until all pre-fetch map data tilescorresponding to the one or more map points of interest have beenreceived at the client device.

In some embodiments, the tile budget is a preset total number of maptiles or preset total amount of map data. In some embodiments, the tilebudget may be checked after the client device has received each of thepre-fetch map data tiles.

In some embodiments a plurality of map points of interest are identifiedfor pre-fetching and that plurality is prioritized in order from highestto lowest, where pre-fetching occurs on the highest priority map pointof interest first.

In some embodiments, the map database stores map data at different zoomlevels, each containing respective sets of map data tiles, such thatpre-fetching of map data tiles occurs at a plurality of the zoom levels.

The features and advantages described in this summary and the followingdetailed description are not all-inclusive. Many additional features andadvantages will be apparent to one of ordinary skill in the art in viewof the drawings, specification, and claims hereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is high-level block diagram of a wireless network depicting awireless base station connected to a server containing map data forselectively communicating that map data to a various client devices onthe network.

FIG. 2 is a block diagram of an example map generator in the clientdevice of FIG. 1.

FIG. 3 illustrates a portion of the data structure for the map databaseof FIG. 1.

FIGS. 4A, 4B, and 4C illustrate example renditions of map data at threedifferent zoom levels, respectively.

FIG. 5 illustrates an example process or flow diagram for identifyingpoints of interest and map zoom levels that are used in requestingpre-fetch map data from a server and for performing a tile budget on thepre-fetch map data from the server.

FIGS. 6A, 6B, and 6C illustrate example renditions of the map data ofFIGS. 4A, 4B, and 4C, at three different zoom levels, respectively, andshowing points of interest at the different zoom levels.

FIG. 7 illustrates an example process or flow diagram for constructingand displaying pre-fetch map data visually.

FIG. 8 illustrates an example process or flow diagram for performing thetile budgeting of FIG. 5.

FIG. 9 illustrates an example process or flow diagram for determiningpoints of interest to be used in identifying the pre-fetch map data.

FIG. 10 illustrates an example process or flow diagram similar to thatof FIG. 5, but which ranks points of interest in priority as part of apre-fetching map data process.

FIG. 11 illustrates an example process or flow diagram for identifyingthe pre-fetch map data in response to the identified points of interest,zoom levels, and tile radii.

DETAILED DESCRIPTION

The present application describes techniques for fetching map data overa selected subset of the entire map data available, by identifying oneor more points of interest for display on client device. The techniques,which may be implemented on a client device such as a mobile or handhelddevice, will access map data pertaining to these points of interest froma remote server. In this way, the techniques do not need to access anentire map database, but rather only a portion thereof. To avoidaccessing too much of the map data, the techniques employ a map memorybudgeting process that allows access to a threshold amount of map data.When the map data is stored at the remote server in the form of map datatiles, the techniques allow the client device to perform tile budgetingon the received map data tiles to limit the amount of map data accessed.

More particularly, the present application describes techniques forfetching map data over a selected subset of the entire map dataavailable, by identifying one or more points of interest for display onclient device, where those points of interest are identified by the userof the client device, for example by the user searching for a particularlocation or direction between locations through a mapping application onthe client device. In other embodiments, the points of interest areautomatically determined by the client device, for example by the clientdevice identifying a set of most recently accessed points of interest ora set of most frequency accessed points of interest. In either case, thepoints of interest are identified to a remote server that contains a mapdatabase of the entire map data, including map data for the points ofinterest. With the points of interest identified, the remove serverbegins transmitting the map data, corresponding to these points ofinterest, to the client device for storage and display to the user.Storing map data in data blocks known as map data “tiles,” the remoteserver sends the map data in the form of a map data tiles. For eachpoint of interest, the server may send an identified set of map datatiles, termed pre-fetch map data tiles. The client device receives thepre-fetch map data tiles until a tile budget has been met, which theclient device may assess upon receipt of each map data tile sent fromthe server or which it may assess periodically, for example, afterreceipt of any subset of map data tiles sent from the server. The clientdevice continues receiving map data tiles until the tile budget is met.In some embodiments, the client device prioritizes the points ofinterest and requests and receives map data tiles in an order accordingto these priorities. If the client device receives all of the pre-fetchmap data tiles for the highest priority point of interest, then theclient device starts requesting and receiving the pre-fetch map datatiles for the next highest priority point of interest, which the clientdevice keeps doing until a tile budget has been met. The tile budget maybe a fixed number of map tiles or it map be a total mount of map datathat is to be stored on the client device.

Pre-fetching refers to requesting map data from a remote map database,such as that of a remote server, prior to any specific user request formap data, so that map data may be collected and buffered on a deviceuntil a specific user request for map data. In this way, pre-fetchingseeks to collect map data in the background, before that map data iscalled upon to construct a visual display, thereby reducing (and eveneliminating) the need for a client device to request map data only aftera user request. The pre-fetched map data is automatically identified,requested, and stored on the client device for subsequent use inconstructing a visual display. As discussed in examples below, wherethat map data is stored in the remote map database in the form of mapdata tiles, the pre-fetching is of map data tiles.

FIG. 1 is a high-level block diagram that illustrates a computingenvironment for a pre-fetch map data system 100 that may be used toaccess and store map data within a map database. As illustrated in FIG.1, the computing environment includes a map database 103 connected to ordisposed within a server 105, which is, in turn, connected to a numberof client devices 115 through a network 125. The network 125 includesbut is not limited to any combination of a LAN, a MAN, a WAN, a mobile,a wired or wireless network, a private network, or a virtual privatenetwork. While only three clients 115 are illustrated in FIG. 1 tosimplify and clarify the description, it is understood that any numberof client computers are supported and can be in communication with theserver 105.

Both the server 105 and the clients 115 are computers that may include aCPU 130 (only shown in the clients), one or more computer readablememories 132, one or more user interfaces 134 (keyboard, touch screen,etc.), a network interface 136, one or more peripheral interfaces, andother well known components. As is known to one skilled in the art,other types of computers can be used that have different architectures.The client devices 115 represent any suitable handheld and/or mobiledevice, such as a mobile phone, personal data assistant, laptopcomputer, tablet personal computer, car navigation system, hand-held GPSunit, or “smart” device. More broadly, the client devices 115 representany personal computing device, database, server, or network of suchdevices, or any other processing device having a user interface and CPUand capable of displaying a visual rendition of map data accessed fromthe map database 103 or other remote source of map data. Furthermore,while in some examples, the network 125 is described as a wirelessnetwork, the network 125 may be any wired or wireless network, where theclients 115 are devices on the network.

The server 105 and the clients 115 are also adapted to execute computerprogram modules for providing functionality described herein. As usedherein, the terms “module” and “routine” refer to computer program logicused to provide the specified functionality. Thus, a module or a routinecan be implemented in hardware, firmware, and/or software. In oneembodiment, program modules and routines are stored on a storage device,loaded into memory, and executed by a processor or can be provided fromcomputer program products that are stored in tangible computer-readablestorage mediums (e.g., RAM, hard disk, optical/magnetic media, etc.).

The map database 103, which may be stored in or may be separate from theserver 105, contains map data that can be used to generate a digital mapor that can be used by, for example, a navigation system to determineroutes between two locations. Physical roads, waterways, parks,landmarks, and other geographic elements may be represented in the mapdata by a list of nodes and segments that connect those nodes. Each nodecorresponds to a specific geographic location in the physical world. Thedata representation for each node generally includes a set ofcoordinates (e.g., latitude and longitude) and an association with oneor more segments. For roads, each segment corresponds to a section of aphysical location that begins at one node and ends at a different node.The data representation for each road segment, for example, can includea length and a number of attributes, such as a street name, a priority(e.g., a highway or a local road), speed information, a surface type, aroad width, an indication of whether the road segment is a one-waysegment, address ranges, usage (e.g., ramp or trail), etc.

The map data stored in the map database 103 can be obtained from severaldifferent sources such as the New York City Open Accessible SpaceInformation System (OASIS) and the U.S. Census Bureau TopologicallyIntegrated Geographic Encoding and Referencing system (TIGER). The mapdata can also be accessed by one of the map generators 120, modified,and stored back into the database 103. Further, the database 103 doesnot need to be physically located within server 105. For example, thedatabase 103 can be partially stored within a client 115, can be storedin external storage attached to the server 105, or can be stored in anetwork attached storage. Additionally, there may be multiple servers105 that connect to a single database 103. Likewise, the map database103 may be stored in multiple different or separate physical datastorage devices.

Each client 115 executes one of the map generators 120, each of whichreceives pre-fetch map data from the server 105 and generates a visualdisplay of the received map data that is presented to the user on adisplay of the interface 134. The map generator 120 is able to adjustthat visual display in response to user interactions with the interface134, for example, adjusting which map data is visualized at any giventime in response to a user selecting to scroll (left, right, up, down,etc.) through the visual display, or in response to the user selectingto change the zoom level (e.g., scale) of the displayed map data.

As illustrated in the detailed example of FIG. 2, the client 115 mayinclude various modules within or associated with the map generator 120,including a database interface module 181 that operates to retrieve mapdata from the server 105 and map database 103. The map generator 120further includes a map point identifier module 182 capable ofidentifying one or more points of interest that are to be used by adisplay module 184 to create a visual map display of received map dataon the interface 134. The points of interest are communicated by theinterface module 181 through the network interface 136 through network125 to the server 105, which responds by sending pre-fetch map data fromthe map database 103 back to the client device 115, where this pre-fetchmap data is received by the database interface module 181 and is storedin a map buffer memory 180 of the client 115. A map data selectionmodule 186 accesses the stored pre-fetch map data and determines whichportion of that buffered map data is to be provided to the displaymodule 184 for creating the visual map display on the interface 134. Themodule 186, therefore, is responsive (after pre-fetching) to userinteraction with the interface 134 to determine which portion of thepre-fetched map data should be displayed to the desires in response to asubsequent user interaction, which is determined by a centralized mapposition, user scrolling, and zoom level, for example.

In the illustrated embodiment, the map generator 120 further includes atile budget module 188 that limits the amount of pre-fetch map datatiles that can be received to the client device. The client 115, forexample, receives map data tiles at the database interface module 181,where upon receipt of one or any predetermined number of map data tilesthe tile budget module 188 determines if the client device 115 hasreceived a sufficient, or threshold amount of map data tiles, at whichpoint the tile budget module 188 instructs the database interface module181 to stop requesting and storing additional map data tiles.

While the tile budget module 188 is described as contained within themap generator 120, in other examples, a tile budget module may be storedin the server 105 or in both the client 115 and the server 105. The tilebudget module 188, for example, may be implemented in the map generator120 of the client 115 or implemented as a standalone or integratedmodule at the server 105. In some embodiments, the database interfacemodule 181 receives zoom level data from a zoom level module 190, whichidentifies at what zoom level the module 181 is to request pre-fetch mapdata tiles. In this way, the client device 115 may receive pre-fetch mapdata at one or more zoom levels to store in the buffer memory 180.

Of course, some embodiments of the map generator 120 may have differentand/or other modules than the ones described herein. Similarly, thefunctions described herein can be distributed among the modules inaccordance with other embodiments in a different manner than thatdescribed herein.

Generally speaking, map data in the map database 103 is stored indifferent zoom levels each formed of a plurality of map data blocks,termed map tiles, which are used to construct a visual display of themap. FIG. 3 illustrates an example data structure 200 of a portion ofthe map database 103. The map data is stored in numerous (n) differentzoom level data structures (only three of which are shown) 202A, 202B,and 202C, where each data structure is formed by a plurality of map datatiles. The data structure 202B, which is the only one numbered forexplanation purposes, shows the map data at zoom level, z=2, is formedof 18 map data tiles, 204A-204R. The map tiles represent the basicbuilding blocks for constructing a map display. Each map tile containsnecessary map data to construct a portion of the map display, includingdata identifying roads, buildings, and geographic boundaries, such aswater lines, county lines, city boundaries, state lines, mountains,parks, etc. The map data may be stored in any number of different zoomlevel data structures. In an embodiment, 19 total zoom levels are storedin the map database 103.

The number of tiles at each zoom level increases, e.g., linearly,quadratically, exponentially, or otherwise. The zoom levels in theillustrated example (z=1, 2, and 5) have 6, 18, and 60 map data tiles,respectively, covering the same geographic area or region.

In some embodiments, each map tile contains map data stored in a bitmapformat, for display to the user using a raster display engine executedby the display module 184. In other embodiments, the map tile maycontain map data stored in vector format, for display using a vectorbuildup display engine executed by the display module 184. In eithercase, the display module 184 may employ a C++, HTML, XML, JAVA, orVisual Basic application for generating a visual display of the maptiles.

In the illustrated embodiment, all map data is stored in map tiles, andeach map tile in a zoom level data structure is allocated the samememory allocation size. For example, each tile 204A-204R may be a bitmapimage 10 Kbytes in size. This may be achieved, for example, by havingeach map tile cover the same sized geographic area. For map tilescontaining vector data, the data size for each tile may vary, but eachtile may still, in some embodiments, be allotted the same maximum memoryspace. Although not illustrated, in other embodiments, the data tileswill have different memory space allocations within a zoom level datastructure.

FIGS. 4A-4C illustrate visual map displays, e.g., that may be fully orpartially displayed on the user interface 134, where each figureprovides a visual display at a different zoom level. In the illustratedembodiments, FIG. 4A provides a visual map display 300 at an examplezoom level, z=6, constructed of a series of map tiles 302-318, whichcover the same size geographic area and which have the same amount ofmemory size.

In operation, the server 105 is able to transmit map data to respectiveclients 115 in chunks of data defined by these map tiles. For example,to transmit the map data needed to construct the map display 300, theserver 105 may transmit each map tile in a frame, having a headerportion providing identification data of the frame (such as geographicposition, client device address, map tile version number, etc.) and apayload portion containing the specific map tile data to be used informing the visual display. Map data tiles provide an effectivemechanism for quantizing map data stored in the map database 103 and forquantizing communication of the map data over the network 125 to theclients 115.

In comparison to FIG. 4A, FIG. 4B illustrates a visual map display 400at a zoom level higher than the zoom level of FIG. 4A, in this examplezoom level, z=10. The map display 400 is formed of a plurality of maptiles 402-432. Like the map tiles 302-318, the map tiles 402-432 areeach the same in size, e.g., covering the same geographic area andhaving the same memory size. FIG. 4C illustrates another visual mapdisplay 500 at a third even higher zoom level, zoom level z=12, formedof map data tiles.

Each of the displays 300, 400, and 500 is of a portion of the overallmap data, which comprises many more map data tiles.

As illustrated across FIGS. 4A-4C, the map tiles that form each visualmap display have various levels of detail. The tiles 302-318 illustrategeographic boundaries, but no roads, only highways and/or interstates,while the tiles of FIG. 4C are at a higher zoom level and containinformation on roads, buildings, parks, end points, etc.

As the zoom levels increase, i.e., as the visual map display focusesdown on a smaller geographic region, the amount of map data may reach amaximum point, beyond which all zoom levels will contain the same mapdata. The number of map tiles needed to construct a map display may varybut the total amount of map data becomes saturated. The zoom levelcorresponding to this point is termed the saturation zoom level andrepresents the zoom level at which all roads, building, parks, endpoints, and other map data elements for a geographic region areprovided. Any additional zoom levels selected by the user merely zoom infurther on these map data elements. In the illustrated example of FIGS.4A-4C, zoom level, z=12, represents the saturation zoom level.

While a user interacts with the visual map displays 300, 400, and 500,the user may wish to scroll around to display other map data near theillustrated map data. Therefore, the client device 115 uses a system tofetch and store a sufficient amount of map data to form the visual mapdisplay while buffering additional map data at the local device 115 toallow efficient user interaction with that display.

FIG. 5 illustrates a routine or process 700 for requesting and receivingmap data tiles from a remote server. At a block 701, the routine orprocess 700 awaits initiation, which may result from user action, suchas a user activating a mapping application on the client device 115.Initiation may also result from user or application initiated searches,direction end points, and stored location accesses by a user orapplication. In some embodiments, the block 701 functions toautomatically initiate the routine or process 700, for example, byperiodically initiating pre-fetching map data. The block 701 may bedesigned to initiate the process every hour, every day, a few times aday, or at any other suitable periodic interval. In some embodiments,that automatic initiation can occur in response to an event unbeknownstto the user of the client device, such as when mobile wireless servicesare initially activated on the client device or when the client deviceenters an entirely new geographic region, such as when a user hastraveled to a city location.

At a block 702, the map point identification module 182 automatically(i.e., without user interaction or initiation) determines one or moremap points of interest to display to a user via the interface 134. Themodule 182 may automatically identify points of interest, for example,by determining a GPS position of the current location of the client 115,by determining most recently searched points of interest, by accessing adatabase of stored points of interest, or by determining the mostrecently visited points of interest (e.g., cities, neighborhoods, etc.).Of course, in some of these cases, the module 182 may determinelocations for which to download map data for storage at the user deviceas a background application and thus without any particular userinteraction. An example further implementation of the module 182 and theblock 702 is described in the routine or process of FIG. 8.

In other examples, the module 182 may manually determine the points ofinterest based on previous user input, for example, through the userproviding an address into a data field presented on the interface 134,or through the user selecting to find a point of interest obtainedthrough interaction with the interface 134 more generally. For example,the user can access a web-browser or other program running on the clientdevice that identifies a location, business, home, etc., from which themodule 182 may allow the user to select such item for building a mapdisplay of the vicinity around such point of interest. Any suitablemanual method for entering or otherwise identifying one or more pointsof interest may be used by module 182 and collected by the block 702.Further still, these manual methods can be modified into automaticmethods of map point identification, by having the block 702 accesshistorical data on previous, manual user data inputs.

FIGS. 6A-6C illustrate the visual map displays (300, 400, and 500) ofFIGS. 4A-4C, respectively, but showing map points of interest identifiedby the module 182. The points of interest that are displayed on the userinterface 134 depending on the zoom level. FIG. 6A illustrates threepoints of interest 602, 604, and 606; while FIG. 6B illustrates only twopoints of interest 604 and 606; and FIG. 6C illustrates only one pointof interest 606.

For convenience purposes the remainder of the routine or process 700will be described in terms of a single map point of interest beingidentified by the block 702. It will be understood, that the same blockswould be executed if multiple map points of interest were identified.

Returning to FIG. 5, at a block 704, one or more desired zoom levels areidentified (by map zoom module 190). If the routine or process 700 isinitiated by the user interacting with a mapping application, the zoomlevel module 190 may identify a zoom level based on the zoom levelselected by the user. In other embodiments, the zoom level module 190may identify the most recently last used zoom level by the user or themost frequently used zoom level as the identified zoom level.

At a block 706, the database interface module 181 communicates the mappoints of interest (block 702) and the zoom level data (block 704) tothe server 105, in particular, in the illustrated embodiment, to apre-fetch data engine 750 at the server 105 (see, FIG. 1). The pre-fetchdata engine 750 then identifies the one or more map points of interestand zoom level(s) and determines the map data corresponding to the oneor more points of interest at the selected one or more zoom levels thatare to be fetched from the map database 103. The engine 750 collects thecorresponding map tiles and begins transmitting that map data to the mapgenerator 120.

In the illustrated embodiment, the block 706 requests pre-fetch map datafor all map points of interest at one time, for example, by sending tothe server a data frame having an identification header that contains,among other things, an identification field identifying the clientdevice and having a payload that identifies the one or more map pointsof interest and the zoom level or zoom levels for which to collect mapdata. The map points of interest may be identified by a longitude andlatitude coordinate, in some embodiments. Optionally, in someembodiments where the block 706 requests all pre-fetch map data at once,the server 105 may send the responsive pre-fetch map data tiles insubsets, i.e., in blocks of one or more map data tiles, but not in acontinuous stream. As each subset of the pre-fetch map data tiles isreceived, the block 706 may send a return signal, in the form of an“acknowledgment” signal, back to the server 105 to confirm receipt ofthe data.

As the map data tiles are received at a block 708, the tile budgetmodule 188 performs a tile budget check on the received map data tilesto determine if a tile budget has been met. If the tile budget has notbeen met, then the client device 115 stores that pre-fetch map datathrough a block 710 (database interface module 181), in the memorybuffer 190. At a block 712, the routine or process 700 determineswhether all pre-fetch map data tiles have been received to the clientdevice 115. If not, then control is passed to block 708 to receivefurther map data tiles and perform tile budget checks. Optionally insome embodiments control is passed to the block 706, which transmits a“continuing request” signal that instructs to the server 115 to send thenext subset of pre-fetch map data tiles. If there are no further mapdata tiles to received from the server, the routine or process 700passes control to a block 713, where the client device 115 awaits someuser interaction, i.e., a subsequent interaction after the pre-fetchingof blocks 701-710. Once as user as performed an interaction that is toresult in rendering (i.e., construction and display) of a visual mapdisplay, through a block 714, the module 186 identifies a subset of thepreviously-stored pre-fetch map data to display to the user on a visualdisplay that is rendered by the display module 184 through a block 716.

If the tile budget check at the block 708 identifies that a tile budgetwill be met by the received map data tile(s), the received map datatile(s) will be stored, if memory allows, by a block 718, and control ispassed to the block 713. This step prevents further map data tiles frombeing received and stored on the client device 115. Optionally, in someembodiments, upon a tile budget being met, the block 706 is instructedto transmit a “stop” instruction signal to the server, which the serverthen interprets and stops from sending any further map data tiles.

FIG. 7 illustrates a routine or process 800 that may be performed by theblocks 714-716 (display module 184), i.e., in response to a user requestfor map data occurring after the pre-fetch map data has beenautomatically collected and stored. The client device 115 maintains allreceived pre-fetch map data from the server 105 in the memory buffer180. At a block 802, the display module 184 identifies an initial subsetof the pre-fetch map data and, at a block 804, constructs and displayson the user interface 134 a visual map display of this initial subset ofthe pre-fetch map data, including one or more map points of interest.The initial display is provided to visualize the map points of interest.The display is an initial display in that the client device will havelikely received and stored a large number of map data tiles, too many todisplay at any given time, irrespective of zoom level; therefore only asubset of the map data tiles are displayed at one time. At a block 806,the display module 184 detects further user interactions with theinterface 134, waiting for the user to interact with the visual displayof map data as the user selects different regions of the map data thatare to be displayed. For example, at the block 806, the display module184 detects a user scrolling across the displayed map data to depictadjacent map data to the initial point of interest. Such scrolling maybe sideways across the display, up or down, or any other desireddirection. The user may also choose to alter the map by changing zoomlevels, either increasing to zoom in further on the map data ordecreasing to zoom further out. The block 806 identifies mapmanipulation user interaction data to the block 802, which thendetermines which other pre-fetched map data, stored in the buffer memory180, is to be displayed in response to the user interaction. Or theblock 806, upon appropriate instruction from the user, terminates theroutine or process 800 entirely, for example, when a user selects toexit a mapping application.

FIG. 8 illustrates a routine or process 900 that may be implemented bythe block 708 (the tile budget module 188). A process 902 analyzes thesubset of pre-fetch map data tiles received from the server 105, wherein the illustrated example such analysis includes incrementing a totalnumber of map data tiles received and determining a total amount of mapdata (measured in kilobytes, megabytes, or gigabytes) received from theserver 105. At a block 904, the tile budget module 188 identifies afirst tile budget criterion. The map generator 120 may use any number oftile budget criteria. The illustrated example is described with respectto two tile budget criteria: a total number of received map data tilesand a total amount of map data. The module 188 initially identifies thetotal number of received map data tiles, in the discussed embodiment. Ata block 906, the tile budget module 188 determines if the tile budgethas been met by the received subset of pre-fetch map data tiles, i.e.,whether the number of received map data tiles exceeds a threshold numberof data tiles stored in the memory 132 of the client device 115. If thefirst tile budget criterion is not met, a block 908 determines if thereare additional tile budget criteria. If there are, control is passedback to the block 904, where the tile budget module 188 identifies thenext tile budget criterion and the steps repeat. Once there are nofurther tile budget criterion, at a block 910 control is passed back toblock 708.

Upon the various tile budget criteria checks of block 906, if the module188 determines that the tile budget has been met, at a block 912, a“stop” instruction is sent to the server 115 (the database interfacemodule 181) to instruct the server to stop sending any additionalpre-fetching map data tiles. The block 914 instructs that control bepassed to the block 714 for storing the received pre-fetch map datatiles, if there is sufficient memory for storing the tiles. If there isnot, the received pre-fetch map data tiles exceeding the tile budget arediscarded.

FIG. 9 illustrates a routine or process 1000 for automatically (prior touser interaction or initiation) determining points of interest as may beused by block 702. The map point identifier module 182 performs a seriesof data polling operations, accessing data stored in the memory 132 toaggregate one or more potential points of interest. At a block 1002, themodule 182 polls current user interaction data or stored user mapinteraction data, such as data on past user interactions with map datadisplayed on the interface 134, including data such as locationshighlighted by the user, map points placed on a map display by the user,and geographic regions most displayed on a map display, for example. Ata block 1004, the module 182 polls data on user searches, identifyinglocations the user has requested be identified on a map display. At ablock 1006, the module 182 polls any other location data, includingcurrent geographic position and stored geographic position. The latterincludes can data such as tracking geographic position of the clientdevice 115 to automatically determine location patterns. For example,the module 182 may collect data on client device locations duringworkweek, Monday-Friday, and use that data for pre-fetching map datadevelop travel patterns of the client device. The module 182 may collectdifferent data to determine different typical travel patterns, and thusdifferent potential points of interest, during the weekend. It is notedthat these examples are described in terms of points of interest, but asused herein, a point of interest represents a particular point on a mapor any region of a map that can be defined (specifically or evengenerally) by a map point.

At a block 1008, the module 182 aggregates the polled potential pointsof interest data and provides this data to a block 1010 which determinesa set of one or more points of interest to be used by block 704 todetermine the corresponding one or more tile radii. The block 1010 maydetermine the points of interest by using a threshold, for example,identifying any points of interest that have been accessed by the user acertain number of times or a certain percentage of time over a givenperiod of time. The block 1010 may determine the points of interestcomparatively, for example, by determining which points of interest arethe most frequently accessed. The block 1010 may make the determinationbased on which points of interest are most recently accessed.

FIG. 10 illustrates a routine or process 1100 similar to that of FIG. 5,but in which a plurality of map points are identified and ranked in apriority order that is used to determine the order in which the clientdevice 115 requests pre-fetch map data from the server 105. At a block1101, the routine or process 1100 awaits initiation, in a similar mannerto that of block 701 in FIG. 5. At a block 1102, the module 182identifies a plurality of map points of interest, for example,performing similar operations to that of block 702 described above,namely, determining the map points of interest based on manual inputfrom and/or automatically identifying map points of interest, from acurrent location of the client 115, most recently searched points ofinterest, stored points of interest, and/or most recently visited pointsof interest. At a block 1104, the module 180 identifies a desired zoomlevel or zoom levels for each of the map points of interest.

At a block 1105, the map point identifier module 182 performs aprioritization on the identified map points of interest, ranking them inorder of priority from a highest to a lowest. The block 1105 thenidentifies a highest priority map point of interest, which a block 1106(module 181) identifies to the remote server 105, more specifically to apre-fetch data engine (not shown). A block 1108 performs tile budgetchecking, similar to that of the block 708 described above, while ablock 1110 stores the received pre-fetch map data tiles if the tilebudget has not been met. If the tile budget has been met, then a block1111 stores the received pre-fetch map data tiles, if possible, andpasses control to a block 1113, where the client device awaits userinteraction like block 713 of FIG. 5, after which at a block 1115, themodule 186 identifies tiles among the stored pre-fetch map data tilesthat are to be used by module 184 (block 1116) for rendering a visualdisplay of the map data.

At a block 1112, the routine or process 1100 determines whether thereare additional pre-fetch map data tiles corresponding to the highestpriority map point of interest. If so, control is passed back to block1108 for receiving additional subsets of the pre-fetch map data tilesand performing tile budget checking or optionally block 1106. Theseadditional pre-fetch map data tiles may be those of different zoomlevels for the highest priority map point of interest, data tilesassociated with areas around or adjacent to the highest priority mappoint of interest, etc. If not, then all pre-fetch map data tiles forthe first map point of interest have been received and stored, and theroutine or process 1100 passes control to a block 1114 which determinesif there is at least one additional map point of interest. If so,control is passed to the block 1105 which identifies the next highestpriority map point of interest and communicates the same to the block1106 which then requests pre-fetch map data tiles corresponding to thatnext highest priority map point of interest. This process continuesuntil pre-fetch map data tiles for all map points of interest have beendownloaded or until the tile budget has been met. If there are noadditional map points of interest, the block 1114 passes control to theblock 1113.

FIG. 11 illustrates an example routine or process 1200 as may beperformed by the server 105, specifically the pre-fetch data engine 750,upon receipt of the identified points of interest and zoom levels at ablock 1202. At a block 1204, the server 105 accesses the map database103, and takes one of the points of interest and identifies the map datacorresponding to that point of interest, at a block 1206. A block 1208identifies a zoom level, e.g., from the zoom level received to block1202, at which to collect the initial set of map data from the database103. For the identified zoom level, a block 1210 identifies the firstpoint of interest collects all map data tiles the correspond to thepoint of interest, which thereby identifies the pre-fetch map dataassociated with that point of interest. For example, if each tile in themap data is stored with an assigned position value relative to the othertiles, such as an assigned longitude value and an assigned latitudevalue or an assigned column value and an assigned row value, then theblock 1210 may identify a pre-determined set of map data tiles adjacentthe map data tile containing the point of interest.

At a block 1212, the server 105 transmits a subset of the identifiedpre-fetch map data tiles collected at block 1210 to the requestingclient device 115, where the requesting client device 115 is identifiedby address information in a header of the data provided to block 1202.The server sends a subset of the pre-fetch map data tiles, which allowsthe client device 115 to frequently perform tile budgeting checks on thereceived data. The subset includes at least one pre-fetch map data tile;and the smaller the subset the more frequently the client device 115will check for whether the tile budget has been reached.

In the illustrated embodiment, at a block 1214, the server 105determines if the client device has identified a need for map datastored at additional zoom levels, where if so, control is passed back tothe block 1208 which identifies the next zoom level and the processrepeats, as described. In some embodiments, the client device 115 (i.e.,the database interface module 181 via block 706), sends requests forpre-fetch map data on a per point of interest basis, i.e., awaitingreceipt of all pre-fetch map data tiles for one point of interest,before identifying the next point of interest to the server 105. Inother embodiments, the client device 115 (again through block 706)requests pre-fetch map data for a plurality of map points of interest atone time. In the case of the later, if no additional zoom level data isrequired for the particular point of interest, then a block 1216determines if additional points of interest have been identified by theclient device, where if so, control is passed back to the block 1206which identifies the next point of interest and the process repeats, asdescribed. If not the routine or process 1200 ends.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

For example, the network 125 may include but is not limited to anycombination of a LAN, a MAN, a WAN, a mobile, a wired or wirelessnetwork, a private network, or a virtual private network. Moreover,while only three clients 115 are illustrated in FIG. 1 to simplify andclarify the description, it is understood that any number of clientcomputers are supported and can be in communication with the server 105.

Additionally, certain embodiments are described herein as includinglogic or a number of components, modules, or mechanisms. Modules mayconstitute either software modules (e.g., code embodied on amachine-readable medium or in a transmission signal) or hardwaremodules. A hardware module is tangible unit capable of performingcertain operations and may be configured or arranged in a certainmanner. In example embodiments, one or more computer systems (e.g., astandalone, client or server computer system) or one or more hardwaremodules of a computer system (e.g., a processor or a group ofprocessors) may be configured by software (e.g., an application orapplication portion) as a hardware module that operates to performcertain operations as described herein.

In various embodiments, a hardware module may be implementedmechanically or electronically. For example, a hardware module maycomprise dedicated circuitry or logic that is permanently configured(e.g., as a special-purpose processor, such as a field programmable gatearray (FPGA) or an application-specific integrated circuit (ASIC)) toperform certain operations. A hardware module may also compriseprogrammable logic or circuitry (e.g., as encompassed within ageneral-purpose processor or other programmable processor) that istemporarily configured by software to perform certain operations. Itwill be appreciated that the decision to implement a hardware modulemechanically, in dedicated and permanently configured circuitry, or intemporarily configured circuitry (e.g., configured by software) may bedriven by cost and time considerations.

Accordingly, the term “hardware module” should be understood toencompass a tangible entity, be that an entity that is physicallyconstructed, permanently configured (e.g., hardwired), or temporarilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. As used herein,“hardware-implemented module” refers to a hardware module. Consideringembodiments in which hardware modules are temporarily configured (e.g.,programmed), each of the hardware modules need not be configured orinstantiated at any one instance in time. For example, where thehardware modules comprise a general-purpose processor configured usingsoftware, the general-purpose processor may be configured as respectivedifferent hardware modules at different times. Software may accordinglyconfigure a processor, for example, to constitute a particular hardwaremodule at one instance of time and to constitute a different hardwaremodule at a different instance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware modules. Accordingly, the described hardwaremodules may be regarded as being communicatively coupled. Where multipleof such hardware modules exist contemporaneously, communications may beachieved through signal transmission (e.g., over appropriate circuitsand buses) that connect the hardware modules. In embodiments in whichmultiple hardware modules are configured or instantiated at differenttimes, communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service” (SaaS). For example, at least some of theoperations may be performed by a group of computers (as examples ofmachines including processors), these operations being accessible via anetwork (e.g., the Internet) and via one or more appropriate interfaces(e.g., application program interfaces (APIs).)

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example embodiments,the one or more processors or processor-implemented modules may belocated in a single geographic location (e.g., within a homeenvironment, an office environment, or a server farm). In other exampleembodiments, the one or more processors or processor-implemented modulesmay be distributed across a number of geographic locations.

Some portions of this specification are presented in terms of algorithmsor symbolic representations of operations on data stored as bits orbinary digital signals within a machine memory (e.g., a computermemory). These algorithms or symbolic representations are examples oftechniques used by those of ordinary skill in the data processing artsto convey the substance of their work to others skilled in the art. Asused herein, an “algorithm” is a self-consistent sequence of operationsor similar processing leading to a desired result. In this context,algorithms and operations involve physical manipulation of physicalquantities. Typically, but not necessarily, such quantities may take theform of electrical, magnetic, or optical signals capable of beingstored, accessed, transferred, combined, compared, or otherwisemanipulated by a machine. It is convenient at times, principally forreasons of common usage, to refer to such signals using words such as“data,” “content,” “bits,” “values,” “elements,” “symbols,”“characters,” “terms,” “numbers,” “numerals,” or the like. These words,however, are merely convenient labels and are to be associated withappropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B are true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Still further, the figures depict preferred embodiments of a map editorsystem for purposes of illustration only. One skilled in the art willreadily recognize from the following discussion that alternativeembodiments of the structures and methods illustrated herein may beemployed without departing from the principles described herein

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for identifying terminal road segments through thedisclosed principles herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various modifications,changes and variations, which will be apparent to those skilled in theart, may be made in the arrangement, operation and details of the methodand apparatus disclosed herein without departing from the spirit andscope defined in the appended claims.

What is claimed is:
 1. A method for selecting map data for storage in amemory of a computing device, the method comprising: determining, by oneor more processors, a plurality of geographic locations for which a userof a client device is expected to subsequently request digital maps;prior to receiving a user request for map data related to the pluralityof geographic locations, determining, by one or more processors,pre-fetch map data for generating digital maps including the pluralityof geographic locations; determining, by one or more processors, amemory budget for storing map data in a memory of the client device;determining, by one or more processors, a priority for retrieving mapdata from a remote database to the memory of the client device; andcausing, by one or more processors, retrieval of at least a portion ofthe determined pre-fetch map data from the remote database to the memoryof the client device in accordance with the determined memory budget andthe determined priority.
 2. The method claim 1, wherein determining thememory budget is based on one or more of (i) a number of map tiles, eachtile corresponding to a portion of a digital map of a fixed size at acertain zoom level, or (ii) a pre-set amount of memory in the clientdevice.
 3. The method of claim 1, wherein determining the priority isbased on which points of interest were most recently accessed by theuser.
 4. The method of claim 1, wherein determining the priority isbased on which points of interest were most frequently accessed by theuser.
 5. The method of claim 1, wherein determining the priority isbased on an amount of time during which a point of interest previouslywas displayed on a digital map.
 6. The method of claim 1, whereinprioritizing the plurality of points of interest based on previous userselections.
 7. The method of claim 1, further comprising: identifying,by one or more processors, one or more zoom levels of the pre-fetch mapdata based on a zoom level most recently used by the user.
 8. The methodof claim 1, further comprising: identifying, by one or more processors,one or more zoom levels of the pre-fetch map data based on a zoom levelmost frequently used by the user.
 9. The method of claim 1, whereincausing the retrieval includes causing the a remote server to transmitat least some of the pre-fetch map data in order from highest to lowestpriority, including: during the retrieval, continuously checking whetherthe tile budget has been met, and causing the client device to stopreceiving further pre-fetch map data when the tile budget has been met.10. A client device comprising: one or more processors; a userinterface; a non-transitory computer-readable memory storing thereoninstructions that, when executed on one or more processors, cause theclient device to: determine a memory budget for storing map data in thememory, prior to receiving a user request for map data related aplurality of geographic locations for which a user of the client deviceis expected to subsequently request digital maps, receive at least aportion of pre-fetch map data for generating digital maps including theplurality of geographic locations, wherein the pre-fetch map data isselected based on the determined budget, and wherein the pre-fetch mapdata is transmitted to the client device from a remote map database inaccordance with a determined priority, and in response to a subsequentrequest for a digital map including one or more of the plurality ofgeographic locations, generate the digital map using the pre-fetch mapdata stored the memory.
 11. The client device of claim 10, wherein theinstructions determine the memory budget based on one or more of (i) anumber of map tiles, each tile corresponding to a portion of a digitalmap of a fixed size at a certain zoom level, or (ii) a pre-set amount ofmemory in the client device.
 12. The client device of claim 10, whereinthe priority is determined based on one or more of: (i) which points ofinterest were most recently accessed by the user, (ii) which points ofinterest were most frequently accessed by the user, (iii) an amount oftime during which a point of interest previously was displayed on adigital map, or (iv) previous user selections.
 13. The client device ofclaim 10, wherein the pre-fetch map data is transmitted in order fromhighest to lowest priority, and wherein the instructions further causethe client device to: during the retrieval, continuously check whetherthe tile budget has been met, and stop receiving further pre-fetch mapdata when the tile budget has been met.
 14. The client device of claim10, wherein the instructions further cause the client device to:identify one or more zoom levels of the pre-fetch map data based on azoom level most recently used by the user.
 15. The client device ofclaim 10, wherein the instructions further cause the client device to:identify one or more zoom levels of the pre-fetch map data based on azoom level most frequently used by the user.
 16. A non-transitorycomputer-readable medium storing thereon instructions that, whenexecuted by one or more processors, cause the one or more processors to:determine a plurality of geographic locations for which a user of aclient device is expected to subsequently request digital maps; prior toreceiving a user request for map data related to the plurality ofgeographic locations, determine pre-fetch map data for generatingdigital maps including the plurality of geographic locations; determinea memory budget for storing map data in a memory of the client device;determine a priority for retrieving map data from a remote database tothe memory of the client device; and cause retrieval of at least aportion of the determined pre-fetch map data from the remote database tothe memory of the client device in accordance with the determined memorybudget and the determined priority.
 17. The computer-readable medium ofclaim 16, wherein the instructions further cause the one or moreprocessors to determine the memory budget based on one or more of (i) anumber of map tiles, each tile corresponding to a portion of a digitalmap of a fixed size at a certain zoom level, or (ii) a pre-set amount ofmemory in the client device.
 18. The computer-readable medium of claim16, wherein the instructions cause the one or more processors todetermine the priority based on one or more of: (i) which points ofinterest were most recently accessed by the user, (ii) which points ofinterest were most frequently accessed by the user, (iii) an amount oftime during which a point of interest previously was displayed on adigital map, or (iv) previous user selections.
 19. The computer-readablemedium of claim 16, wherein the instructions further cause the clientdevice to: identify one or more zoom levels of the pre-fetch map databased on a zoom level most recently used by the user.
 20. Thecomputer-readable medium of claim 16, wherein the instructions furthercause the client device to: identify one or more zoom levels of thepre-fetch map data based on a zoom level most frequently used by theuser.